The present invention generally relates to wireless communication devices and, more specifically, to short-range radio links for communication between electronic devices, which may be portable.
Bluetooth™ wireless technology is intended to allow wireless connections enabling links between mobile computers, mobile phones, portable handheld devices, and connectivity to the Internet. The specification is developed, published and promoted by the trade association Bluetooth Special Interest Group (SIG), also referred to as Bluetooth SIG, Inc. For example, “Specification of the Bluetooth System”, Core, Version 1.1, Feb. 22, 2001, is available from the website www.bluetooth.org and incorporated herein by reference. The Bluetooth™ wireless specification defines a low-power, low-cost technology that provides a standardized platform for a short-range (i.e., maximum transmit output power limited to 100 milli-Watts (mW)—equivalently 20 decibels relative to one milli-Watt (dBm)—as specified in the Bluetooth™ wireless specification) radio link for eliminating cables between mobile devices and facilitating connections between products. It is envisioned that Bluetooth™ technology may be used, for example, to eliminate the need for wired connections between electronic products and accessories; to exchange files, business cards, and calendar appointments with groups of Bluetooth™ users; to transfer and synchronize files between devices; to connect to localized content services in public areas; and to function as remote controls, keys, tickets, and e-cash wallets.
The Bluetooth™ wireless specification includes both link layer and application layer definitions. Radios that comply with the Bluetooth™ wireless specification operate in the unlicensed, 2.4 GHz radio spectrum ensuring communication compatibility worldwide. As shown in FIG. 1, a Bluetooth™ wireless communication device 100 may consist of a radio unit 102, a link controller 104, and a link manager 106. Device 100 may interface to host 108, which may be an electronic device such as a cell phone or laptop computer, for which a short-range radio communication link using Bluetooth™ is desired. Device 100, with its associated host 108, may also be referred to as a Bluetooth™ unit. Link controller 104 carries out the baseband protocols and other low-level link routines, i.e., processes or algorithms, as specified by the Bluetooth™ baseband specification, and may also perform other algorithms such as data partitioning. Link manager 106 may carry out the link manager protocols (LMP), the logical link control and adaptation layer protocol, referred to as L2CAP, and may incorporate the host controller interface (HCI), as specified by the Bluetooth™ baseband specification.
While point-to-point connections, i.e., there are only two Bluetooth™ units involved, are supported, the Bluetooth™ specification also supports point-to-multipoint connections, allowing up to seven simultaneous connections to be established and maintained by a single radio. For example, FIG. 2a shows a point-to-point connection 201 between a first Bluetooth™ unit 202 and a second Bluetooth™ unit 204. Bluetooth™ units 202, 204 may each include a Bluetooth™ wireless communication system—such as system 100 including an associated host 108 for each system, such as a cell phone or personal computer. In a point-to-multipoint connection 203, as illustrated in FIG. 2b, the channel is shared among several Bluetooth™ units, such as Bluetooth™ units 206, 208, 210, and 212 seen in FIG. 2b. Two or more units sharing the same channel form a piconet—such as piconets 214 and 216 seen in FIGS. 2a and 2b. In a piconet, one Bluetooth™ unit acts as the master of the piconet, whereas the other unit(s) acts as slave(s). For example, Bluetooth™ unit 202 acts as master of piconet 214, Bluetooth™ unit 204 acts as slave of piconet 214, Bluetooth™ unit 206 acts as master of piconet 216, and Bluetooth™ units 208, 210, and 212 act as slaves of piconet 216. Each piconet can have only a single master. Up to seven slaves can be active in a piconet. For slaves, the channel access is controlled by the master, and slaves are synchronized to the master. FIG. 2c illustrates a scatternet 218, wherein three piconets connect to each other.
Communication between Bluetooth™ units may be conceptualized as occurring on several different layers concurrently. As illustrated in FIG. 3, communication 301 may occur between first Bluetooth™ unit 302 and second Bluetooth™ unit 304. For example, first Bluetooth™ unit 302 may act as a master—such as Bluetooth™ unit 202 in piconet 214, and second Bluetooth™ unit 304 may act as a slave—such as Bluetooth™ unit 204 in piconet 214. Communication 301 may take place at several different layers, for example, high level layer 306, network layer 308, link layer 310, and the physical layer referred to as baseband layer 312. Information may be exchanged between layers, as represented by arrow 314 and arrow 316. The link manager protocols—LMP 318, 320—and the logical link control and adaptation layer protocols L2CAP 322, 324—may be included in link layer 310.
At the physical layer—baseband layer 312—wireless communication in Bluetooth™ is over a slotted, time division duplex (TDD) channel between the master, for example, first Bluetooth™ unit 302, and the slave, for example, second Bluetooth™ unit 304. For example, it may be specified that the master transmits during even numbered time slots while the slave transmits during odd numbered time slots. The nominal length of each time slot for Bluetooth™ wireless systems is 625 microseconds.
Thus, the data to be transmitted is partitioned into baseband packets before being transmitted over the air. FIG. 4 shows a standard packet format for a baseband packet 400 according to the Bluetooth™ baseband specification. Baseband packet 400 may be formatted into various portions, the length and content of which may vary depending on the type of packet. For example, baseband packet 400 may include an access code 402 containing 72 bits of data, which may be relevant, for example, to the various link management protocols. Baseband packet 400 may include a header 404 containing 54 bits of data, some of which may be used for describing the payload data 406. Payload data 406 may contain data from a higher layer packet of data. The length Lk of payload data 406 may vary, for example, from 0 to 2,745 bits and may or may not be encoded with a forward error correcting code (FEC) depending on the type of packet. In Bluetooth™, there are six types of packets that are of particular interest for the transmission of data, which are briefly summarized in Table 1, below.
TABLE 1Lk(TX)kPacketLength (user(number ofktypebytes)time slots)1DM11712DH12713DM312134DH318335DM522456DH53395The “DH” are mnemonic designations representing “data—medium rate” and “data—high rate”, respectively. The number k, ranging from 1 to 6, is used as an index so that any particular packet can be referred to as a packet of type k. For example, the DM1 packet type may be referred to as a type 1 packet. Payload 406 for the medium rate packet types (with an “M” in their names) are FEC coded using a (10, 15) Hamming code. Payload 406 for the high rate packet types (with an “H” in their names) are not FEC coded. Depending on the length of the packet, the time (TX)k required for the transmission of the packet may be 1, 3, or 5 time slots, as shown in Table 1. Thus, there are packets of three different lengths (1; 3; and 5 time slots long), with coded and uncoded packets for each length. While the uncoded (“H”) packets have a higher data rate, briefly described as the amount of payload 406 user data transmitted per unit of time, than the coded (“M”) packets of the same length, they are more prone to error (because of not being coded) and are likely to have higher retransmission rates. Similarly, longer packets may have higher data rates but are also likely to have higher retransmission rates. During communication, the Bluetooth™ upper layers—such as link layer 310—including L2CAP 322, 324—typically give the baseband layer 312 a higher layer packet of data, i.e. payload 406 data, to be transmitted. Typically, the length of the higher layer packet of data is of the order of several baseband packets. The baseband layer 312 is required to partition the higher layer packet of data into baseband packets 400 and transmit the baseband packets 400 over the air.
The Bluetooth™ baseband layer 312 implements an automatic repeat request scheme, wherein each packet of type k, transmitted by the transmitting unit—such as first Bluetooth™ unit 302—has to be explicitly acknowledged by the receiving device—such as second Bluetooth™ unit 304. A positive acknowledgement (ACK) would mean successful reception whereas a negative acknowledgement (NAK) would mean a failure to receive the packet. The device transmitting the packet—such as first Bluetooth™ unit 302—would retransmit it until either an ACK is received or a timeout is hit. Because there are different types and lengths of baseband packets, different retransmission rates may be expected for each different type and length of packet. In addition, varying channel conditions, such as the presence or absence of radio interference, may also affect the retransmission rates for each different type and length of packet. It is desirable that a data packet partitioning algorithm implemented in baseband layer 312 should partition transmit data into packets of types that achieve high throughput, i.e., high efficiency expressed as the amount of data transmitted per unit of time.
As can be seen, there is a need for a method that; when given a chunk of data by the upper layers, partitions the chunk of data into packets of various types such that the total time needed to successfully transmit the chunk of data is the least amount possible for the types allowed; thus maximizing the data throughput on a radio channel.